Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/[e-mail]_Mon Apr 11 05:28:52 1994.msg

Internet Message Format | 1994-04-30 | 28KB

Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA13912; Sun, 10 Apr 1994 20:16:05 -0400
Received: by usage.csd.unsw.OZ.AU id AA22107
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 10:15:46 +1000
Received: by atlas (4.1/1.35)
    id AA01926; Mon, 11 Apr 94 10:28:53 EST
Message-Id: <9404110028.AA01926@atlas>
From: [e-mail]
Date: Mon, 11 Apr 1994 10:28:52 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: setoptsock()

Thus expounded Franklin S. Cheng on Apr 8,11:19pm:
/--------------------
|
|Fellow hackers,
|
|setoptsock() allows socket programmers to modify the socket
|options, like the buffer size for sending and receiving.(using
|level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF)
|
|My question is when the  _receiving_  buffer size is bigger than one UDP packet,
|say 5 times. Will the incoming 5 packets be held in the buffer if
|the app doesn't read it ? Or no matter how big the buffer size is,
|it always holds just one UDP packet and discard the subsequence UDP
|packets if the apps doesn't read it ? What about if the buffer size
|is 5.3 times of the size of the incoming UDP packets , would the
|6th one be stuffed into the remaining buffer size -- .3 of the UDP
|packet ?

Most of this is implementation dependent - UDP is _not_ a reliable
protocol, and datagrams can be lost at any stage - even once they have
safely negotiated the cables and are inside the machine!

On the other hand, an implementation that prevented th euser from
receiving all the packets possible would be seriously deficent.

All I can describe is our implementation, which (naturally) I believe
to be the only sensible method :)

Multiple incoming UDP packets are queued, unless the new packet would take
the total aggregate buffer size over the receive buffer limit - i.e.
in your example above, if the receive buffer was 5.3 times larger than
the incoming packets, the first 5 would be queued, the sixth and subsequent
packets would be dropped until some of the successful packets have been read.

On the other hand, we don't implement changing the UDP receive buffer at
all, so calling setsockopt(SO_RCVBUF) ona UDP socket doesn't acheive
a great deal! (its conceptually 4K fixed presently). This may be implemented
soon.

|And how about the _sending_ buffer for this case ?

Actually, I don't believe the concept of a sending buffer is applicable for
a UDP socket - each send() by the application results in a separate
datagram, which can be sent immediately to the output interface. If you
send too many too fast for the interface, they get dropped from the output
interface queue, which is totally unrelated to any socket.
|
|thanks,

Anytime.

|
|Franklin.

Cheers,


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Apr 11 06:01:34 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA18479; Sun, 10 Apr 1994 20:49:09 -0400
Received: by usage.csd.unsw.OZ.AU id AA23690
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 10:48:30 +1000
Received: by atlas (4.1/1.35)
    id AA02023; Mon, 11 Apr 94 11:01:36 EST
Message-Id: <9404110101.AA02023@atlas>
From: [e-mail]
Date: Mon, 11 Apr 1994 11:01:34 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: Closing and reusing sockets

Thus expounded Bryan Boreham on Apr 8,11:40pm:
/--------------------
|>From Paul Brooks, [e-mail]:
|
|>True, but you still have to think about the case where your local machine
|>has closed the socket down OK, allowing you to BIND to the same
|>port number in the future, but the REMOTE end still has the same
|>port/address association valid, probably in TIMEWAIT state for two minutes.
|>
|>In this case, your bind() will succeed, but the remote end may well refuse
|>the connection. WSAEADDRINUSE is a valid return from connect(),
|
|Aha!  I was working on the assumption that EADDRINUSE referred to the
|*local* address, not the remote address.  The spec doesn't specify --
|is there any other explicit reference?  I see that Stevens "Unix Network
|Programming" does use it as you describe in the rcmd example, page 570.

I wasn't aware of the passage, I was remembering some bad experiences I have
had, making unwarranted assumptions that just because one end has forgotten
about a previous connection, the other end has too.

When you look at the sequence of closing a socket - the FIN, FIN/ACK, ACK
exchange - its the end that initiates the first FIN that ends up in the
two minute long TIME-WAIT state, while the other end can forget the
connection completely. For client/server things, usually its the
server end that ends up doing this, in response to a signal from the client
(i.e. Telnet, where the server closes the connection after the user
types 'logout' or '^D', or FTP data connections, where the end thats sending
does the close).
    In this case, the local end can successfully bind() to a previously
used local port, and connect() to a previously used remote port.
When the SYN gets to the remote end, however, it may find a matching
socket in TIME-WAIT, and the remote end may refuse the connection.

|However, exactly the same circumstances didn't result in a failure at all
|using the Trumpet stack.  I think I'll do some network sniffing to see if
|I can spot what is different.

Just because this is a possible (and probable) connection failure mechanism,
I'm still not sure how the local end would distinguish this case and return
WSAEADDRINUSE for the connect() return, instead of the more usual
WSAECONNREFUSED. Possibly if the remote end returned a FIN, believing the
new SYN to be an artifact of the previous connection.
|
|Here is one specifc case: suppose a program uses rsh twice in
|succession, something which is very easy in the Alex language.  We must
|bind to a free reserved port locally, and we must connect to the same
|remote port each time.  We would like to do this reliably on any of
|the dozen or more Winsock stacks that our customers might use, with
|the minimum of hack work-arounds that "just happen to fix it".

Use the two-tiered loop around connect() and bind() - don't assume that
just because you can bind() to a local port, that the following connect()
will succeed. This should work, even with potentially broken stacks that
can't check sockets at bind() time properly.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Apr 11 09:52:24 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA19791; Mon, 11 Apr 1994 00:39:11 -0400
Received: by usage.csd.unsw.OZ.AU id AA04534
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 11 Apr 1994 14:39:22 +1000
Received: by atlas (4.1/1.35)
    id AA03112; Mon, 11 Apr 94 14:52:24 EST
Message-Id: <9404110452.AA03112@atlas>
From: [e-mail]
Date: Mon, 11 Apr 1994 14:52:24 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail], [e-mail]
Subject: Windows Sockets 1.1 errata list.

This is a list of typos and minor irritants I have found in the
WinSock 1.1 spec. I'm listing them here since it is likely to me that the
2.0 spec. will borrow much of the text of the 1.1 document, and I
would like to see them cleared out for the 2.0 document.

I'm also listing some minor issues that need clarifying text within the
1.1 spec, in the hope that they will be included in the 2.0 document, and
possibly also in a '1.1 addendum' document.

I won't be able to attend the V2.0 discussions at Winsockathon, but would
like these issues tabled for discussion there.

Typos etc.
----------
Page 25:        Superfluous 'r' character just above '4.1.4 connect()
                should be removed.

Page 26:        WSAEINVAL is not a possible error code for connect(), and
                it should be removed. Connect() will perform an automatic
                internal bind() if required, as already described in the
                Remarks section.

Page 27:        Add text to WSAEFAULT error explanation:
                ..., or one or both of name and namelen are not valid
                pointers.

Page 29:        The type of optname (int) clashes with the declared type
                of the SO_DONTLINGER socket option in WINSOCK.H (u-int).
                Suggest changing WINSOCK.H to make SO_DONTLINGER a signed
                integer to accomodate developers using strict environments.
                e.g.     #define SO_DONTLINGER (int)(~SO_LINGER).

Page 36:    Add 'WSAEFAULT    argp is not a valid pointer' to Error Codes
        section.

Page 42;    Add 'WSAEFAULT  buf is not a valid pointer' to error codes
        section.

Page 43:    second-last paragraph in Remarks section, bottom of page:
        "If the connection has been reset recv() will fail..." -
        recv() should be recvfrom().

Page 44:    The WSAEFAULT explanation should begin "The from and/or
        fromlen argument(s) was invalid"

Page 47:    Add "WSEFAULT    one of the argument pointers was invalid"
        to Error Codes Section.

Page 55:    In setsockopt, in the table at top of P55, the line for
        SO_ERROR should be removed, its a hangover from a block copy
        from getsockopt().

Page 60:    Halfway down in the explanation of the members of the
        hostent structure, the "(PC)" should be removed from
        the h_name entry - theres nothing specific in a hostent
        entry for a PC, and the return from gethostbyYYY need not
        be a PC.

Page 62:    The title at the top of the page containing '4.2.2
        gethostbyname' reads 'gethostname', wheras the actual
        'gethostname' page is the next one. This should be changed
        to 'gethostbyname'.

Page 69:    Remarks section: "getservbyport() returns a pointer to a .."
                                    ^^^
        Word 'to' must be inserted.

Page 105:    Remarks section, 2nd para., 4th sentence currently reads
        "If this version is higher than the lowest version supported
        by the DLL". I beleive this should read "... higher or equal to
        ...". Implementations using this literally may fail to
        correctly register v1.1 applications when the DLL supports
        versions v1.1 and higher (e.g. 2.0).


Clarifications and minor additions
----------------------------------

Page 25/26: connect().
        The BSD form of connect() allows multiple connect() functions
        to be called for SOCK_DGRAM (And presumably SOCK_RAW)
        sockets, to change the remote destination binding. Also,
        it allows connect()ing to an invalid address (usually
        all zeros) to mean 'disconnect' the socket, and start
        accepting datagrams from all remote sources.

        For this functionality to be described by the Winsock Spec,
        the following alterations need to be made:

        remarks section, 1st para, change last sentence to:
        "..., connect() will return WSAEDDRNOTAVAIL for SOCK_STREAM
        sockets. Datagram-based sockets (SOCK_DGRAM, SOCK_RAW)
        will be 'disconnected', and start accepting datagrams from
        multiple remote sources.

        Add new sentences to last paragraph about SOCK_DGRAM
        sockets:
        "Multiple connect() calls may be used to alter the default
        remote destination, and a connect() call with a name containing
        all zeros will return the socket to a 'dis-connected' state.

        Error codes: Add (SOCK_STREAM only) to the explanation for
        WSAEADDRNOTAVAIL and WSAEISCONN error codes.

P35, ioctlsocket().
        The argp argument points to a 'u_long FAR *', and all commands
        except SIOCATMARK specify their arguemnts to be real unsigned
        long values. SIOCATMARK, however, states that 'argp' points
        to a BOOL. Now a BOOL is defined as an int, which size
        is different on different processor architectures, and it is
        unclear whether this command should operate on a 16-bit
        or 32-bit quantity - there exist implementations of DLLs
        and applications that assume both - this confusion is very bad
        for interoperability.

        I beleive the best solution is for ioctlsocket() to
        always operate on 32-bit (or at least, 'u_long') quantities,
        and that the last sentence on page 35 should read something
        like: "argp points at an unsigned long, in which ioctlsocket()
        stores the result: either FALSE (0) or TRUE (!0)."

P 48, send()
        The description for send() seems to prohibit the harmless
        practice of calling send() with a length of 0. A recent
        poll conducted by myself came back 4:1 in favour of
        send() allowing a length of 0, and in this case the valid
        return code of 0 indicates 'all requested data sent' as
        expected. This seems to be common practice in many,
        but not all implementations, anyway. I propose the
        third paragraph in the Remarks section add some text to
        legitimise this practice.



--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Apr 11 10:06:49 1994
Received: from ormail.intel.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA24399; Mon, 11 Apr 1994 21:06:53 -0400
Received: from ccm.hf.intel.com by ormail.intel.com
    (Smail3.1.28.1 #2) id m0pqWwD-000MNbC; Mon, 11 Apr 94 18:06 PDT
Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 11 Apr 94 18:06:49 PST
Date: Mon, 11 Apr 94 18:06:49 PST
From: David B Andersen <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WSAENOBUFS error from WSAAsyncGetXXXByYYY

     IMHO, the correct behaviour is to return the async task handle (what a
     misnomer!) and then post a message with the WSAENOBUFS error code.  My
     reasons for believing this is that WSAENOBUFS is *not* one of the
     defined error codes for the situation when the asynchronous operation
     could not be (or simply was not) launched.

     --Dave B. Andersen
       Intel Architecture Labs


______________________________ Reply Separator _________________________________
Subject: WSAENOBUFS error from WSAAsyncGetXXXByYYY
Author:  [e-mail] at Internet_Gateway
Date:    4/9/94 1:21 AM


I've got a problem with my stack testing, and would like to
take another straw poll (results of the last one soon!)

The application is expecting all error returns from WSAAsyncGetXXXByYYY
routines to be returned along with the completion message.
Some conditions, however, are detectable at the time the call is made.
The one causing the trouble at the moment is WSAENOBUFS. If the application
calls WSAAsynGetHostByName with buf==NULL, I fail the call immediately,
instead of accepting the call then immediately posting a message with
WSAENOBUFS in LPARAM. Now failing the call immediately seems to be perfectly
valid from my reading of the spec - what do you all do/say/expect?


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Apr 13 04:08:23 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA15014; Tue, 12 Apr 1994 18:55:19 -0400
Received: by usage.csd.unsw.OZ.AU id AA25725
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 13 Apr 1994 08:55:16 +1000
Received: by atlas (4.1/1.35)
    id AA03728; Wed, 13 Apr 94 09:08:24 EST
Message-Id: <9404122308.AA03728@atlas>
From: [e-mail]
Date: Wed, 13 Apr 1994 09:08:23 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail]
Subject: WSAAsyncGetXXXbyYYY returns revisited

Recently I posted asking for opinions on failing WSAAsyncGetXXXbyYYY calls
immediately, if the implementation could decide then the call would not
succeed, i.e. if the buffer parameter was NULL.
    While I had a couple of messages indictaing it seemed a fair thing
to do, Scott Robins reminded me:

Thus expounded Question Reality  11-Apr-1994 0956 -0400 on Apr 11, 9:56am:
/--------------------
|
|I think that failing it immediately would be a reasonable action.  However,
|I just don't think that the spec reads that way.  And since V1.1 is already
|out there, I don't see a need to change this behaviour.


...and after reading the spec again carefully, I realise I was
mis-interpreting the text, and that it is reasonably explicit in saying
that only if the call could not be initiated or queued for some reason
should the initial call fail.
    I agree with Scott here - it might be a reasonable thing to do,
but it isn't compliant with the published spec. - so I'll be
changing our stack.

Thanks all.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Apr 16 02:02:00 1994
Received: from gw1.att.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA07149; Fri, 15 Apr 1994 22:02:47 -0400
To: [e-mail]
Received: from hosv1.UUCP by ig1.att.att.com id AA29976; Fri, 15 Apr 94 22:02:51 EDT
Message-Id: <[e-mail]>
From: [e-mail]
Date: 16 Apr 94 02:02:00 GMT
Apparently-To: [e-mail]

I will be away from the office from April 18, 1994
until April 25,1994.  I will pick up e-mail messages
on or about April 25, if you have a question or concern
that can not wait until that time, please call x-3800 for
system related problems or concerns or x-4464 for plotter
releated problems or concerns.

Dudley
From [e-mail] Mon Apr 18 05:37:47 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA29318; Sun, 17 Apr 1994 20:24:25 -0400
Received: by usage.csd.unsw.OZ.AU id AA24894
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 18 Apr 1994 10:24:32 +1000
Received: by atlas (4.1/1.35)
    id AA05577; Mon, 18 Apr 94 10:37:48 EST
Message-Id: <9404180037.AA05577@atlas>
From: [e-mail]
Date: Mon, 18 Apr 1994 10:37:47 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail], Multiple recipients of list <[e-mail]>
Subject: Re: setoptsock()

Thus expounded Bob Quinn on Apr 15,10:01pm:
/--------------------
|>  setoptsock() allows socket programmers to modify the socket
|>  options, like the buffer size for sending and receiving.(using
|>  level= SOL_SOCKET and optname= SO_RCVBUF and SO_SNDBUF)
|>
|>  My question is when the  _receiving_  buffer size is bigger than one UDP packet,
|>  say 5 times. Will the incoming 5 packets be held in the buffer if
|>  the app doesn't read it ? Or no matter how big the buffer size is,
|>  it always holds just one UDP packet and discard the subsequence UDP
|>  packets if the apps doesn't read it ? What about if the buffer size
|>  is 5.3 times of the size of the incoming UDP packets , would the
|>  6th one be stuffed into the remaining buffer size -- .3 of the UDP
|>  packet ?
|
|The spec is clear: "if the datagram is larger than the buffer
|supplied, the buffer is filled with the first part of the
|datagram, the excess data is lost, and recv() returns the
|error WSAEMSGSIZE."  Where's the ambiguity?  Basically, if
|you snooze, you lose :)

Bzzt: sorry Bob, I think you are talking about the wrong buffer.
I beleive that passage you quoted refers to the buffer provided by the
caller in the recv() call - if the LEN parameter is only, say,
1K, and the queued datagram is, say, 2K, thn you only get the first
1K of the queued datagram, as you said.
    The question, on the other hand, was about the internal socket
buffer for all the queued datagrams - the one affected by the SO_RCVBUF
socket option. This is a different kettle of fish.

|I admit, we violate the spec in this regard.  But I contend
|that we are justified in doing so because the lack of an
|asymmetrical send/recv iMaxUdpDg represents a deficiency in
|the specification.
|
|Comments?

Given that fragmentation of outgoing datagrams is simple, all the way up to
the full 64K size of a maximum IP datagram, I don't believe any implementation
_will_ have a need for a separate limit on the size of outgoing UDP datagrams,
and that the iMaxUdpDg parameter relates to the maximum size the implementation
is prepared to re-assemble from incoming fragments. Otherwise you get people
setting up 'black holes' when they set things up to use the same
maximum-size UDP datagrams out and in. If you have a separate size of
maximum outgoing and maximum incoming datagrams, the iMaxUdpDg parameter
should be set to the lower of these, to warn the poor application that
the underlying stack may be insufficient for its requirements.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Apr 18 05:48:32 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA00619; Sun, 17 Apr 1994 20:35:59 -0400
Received: by usage.csd.unsw.OZ.AU id AA25378
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 18 Apr 1994 10:35:15 +1000
Received: by atlas (4.1/1.35)
    id AA05611; Mon, 18 Apr 94 10:48:32 EST
Message-Id: <9404180048.AA05611@atlas>
From: [e-mail]
Date: Mon, 18 Apr 1994 10:48:32 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail], Multiple recipients of list <[e-mail]>
Subject: Re: closesocket()/WSACleanup() question

Thus expounded Bob Quinn on Apr 15,10:26pm:
/--------------------
|One of our customers recently brought a statement in the documen-
|tation for WSACleanup() to my attention.  I am amazed that the
|section he quoted made it into the specification at all, let alone
|the fact it's never been questioned since.  Here is the customer's
|message text (forwarded with his permission):
|
|>  I see this as a bug in the implementation.  There shouldn't
|>  be any need to wait for the TCP close to complete before the
|>  call to WSACleanup().  Winsock spec 1.1 said
|>
|>       "Any open SOCK_STREAM sockets that are connected when
|>  WSACleanup() is called are reset; sockets which have been closed
|>  with closesocket() but which still have pending data to be sent
|>  are not affected--the pending data is still sent."
|>
|>  As you see, it explicitly said that in the last statement.  This
|>  is also comfirm by the same behavior in other TCP/IP vendors such
|>  as Lan Workplace, BW, and NetManage.
|
|This requirement is inappropriate for a few reasons:

[etc]

My thoughts are that these requirements can be met, _PROVIDED_ this is not
the last app. to call WSACleanup() - in this case, the DLL stays in memory
and can manage the data. The requirements are still met by specific
implementations - ours, where a DOS TSR manages the sending of data,
independently of the presence or absence of a DLL, and probably a similar
case if a VxD is used.
    Bob is correct, though - those requirements are not appropriate in
general, and cannot be guaranteed by a pure DLL implementation of Windows
Sockets, because the DLL will have to chuck the data when it unloads. I guess
they might be beleiving an application will call WSACleanup(), then hang
araound for a while doing other things, or something.

I agree, Bob, - there is no way to guarantee in all cases that data pending
to be sent on a closed socket will still be sent after WSACleanup() is
called, no matter what the spec. says.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Apr 18 13:55:56 1994
Received: from arthur.crpht.lu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA20414; Mon, 18 Apr 1994 06:56:45 -0400
Message-Id: <[e-mail]>
Received: from buster.crpht.lu by arthur.crpht.lu with SMTP
    (1.37.109.4/16.2) id AA18472; Mon, 18 Apr 94 12:57:05 +0200
X-Sender: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 18 Apr 1994 12:55:56 +0100
To: [e-mail]
From: [e-mail] (Roger Kries)
Subject: Q: How to connect with a timeout ?

I'm having some problems writing Berkley Sockets API compatible code to
connect to a machine with a timeout value. That's to say, I want to
connect to a machine, but if I cannot connect until the timeout is
elapsed I give up.

My solution was to call connect() on a non-blocking socket and then to
call select() with the timeout value and to check if the socket is
writeable.

This method is described in the Winsock specification at page 25:
> On a non-blocking socket, if the return value is SOCKET_ERROR an
> application should call WSAGetLastError(). If this indicates an error
> code of WSAEWOULDBLOCK, then your application can either:
> 1. Use select() to determine the completion of the connection by
> checking if the socket is writeable, or
> 2. ...
The second method is not Berkley Sockets compatible.

All this seems to be very fine, but after testing the method on
a PC with Trumpet Winsock.dll, on a macintosh with a special socket
library (GUSI) and on a HP-UX machine, the following problem arises:

 If at the moment of the connect call, the remote machine has no socket
 created that listens to the specified port, the following select() call
 will always timeout, even if during the timeout interval a program is
 started that listens to the port. That means that in the case where a
 blocking connect call would return ECONNREFUSED, a non-blocking returns
 WSAWOULDBLOCK, but the select call always timeouts.

So how can I find out if the remote machine is listening to a specific
TCP port without blocking and in a Berkley Socket compatible manner?

Any suggestions are welcome. Thanx in advance.